Wireless point of sale transaction

ABSTRACT

A transaction request by a first customer device is processed by a transaction system. The transaction request is approved by transmitting a data signal from the first customer device to the transaction system via a wireless communications link. Respective wireless communications links are established between the transaction system and a number of customer devices corresponding to respective customers. The first customer device is identified among the number of customer devices having established respective wireless communications links as being a customer device carried by a selected customer.

This application is the U.S. national phase of international applicationPCT/EP02/02461, filed Mar. 5, 2002, which designated the U.S. Priorityis claimed to U.S. provisional patent application 60/304,071, filed Jul.11, 2001. This invention relates to the processing of a transactionrequest by a customer device and a transaction system.

FIELD OF THE INVENTION

This invention relates to the processing of a transaction request by acustomer device and a transaction system.

BACKGROUND

Electronic transaction systems, such as credit card terminals with acard reader physically connected to a point of sale (POS) system, areknown. The increasing availability of mobile terminals, such as mobilephones, have made it desirable to utilise mobile terminals forperforming transactions like the payment for goods. U.S. Pat. No.6,175,922 describes a method of approving a transaction request betweena POS system and a portable electronic customer device, where thecustomer device receives a request for approving a transaction via awireless communications link and, in response to an input from a user,approval data is returned from the electronic customer device to the POSsystem.

However, the above prior art method involves the problem that itrequires a long time for checking out a given customer. When thecustomer reaches the check-out counter and it is his turn to pay, thecashier needs to enter a unique ID of the portable customer device, suchas a phone number, into the POS system in order to enable the POS toestablish the wireless communications link with the customer device.Alternatively, the customer needs to enter a unique transaction ID orPOS ID into the portable customer device for the customer device to beable to contact the POS. Hence, this procedure involves the disadvantagethat the time necessary from when the customer reaches the check-outcounter until the actual transaction may be performed is rather long,thereby reducing the throughput of the POS. Furthermore, if a unique POSID, such as a phone number, is used for an identification of the POS,there is a risk that another customer attempts to communicate with thesame POS at the same time, resulting in a race condition. This may causethe transaction request to be sent to a wrong customer device, causingerroneous transactions and/or the need to repeat a transaction,resulting in increased transaction times and reducing the reliability ofthe method.

SUMMARY

The above and other problems are solved by a method of processing atransaction request by a first customer device and a transaction system,the transaction request being approved by transmitting a first datasignal from the first customer device to the transaction system via awireless communications link; the method comprising the steps of

establishing respective wireless communications links between thetransaction system and a number of customer devices corresponding torespective customers; and

identifying the first customer device among the number of customerdevices having established respective wireless communications links asbeing a customer device carried by a selected customer.

An advantage of the technology is that it provides short transactiontimes. A number of communications links are established to a number ofcustomer devices and, subsequently, the customer device corresponding toa specific customer is identified among the possible customer deviceswhich already have a communications link established. Hence, the actualtransaction between the POS system and a given customer may proceedimmediately after the customer has been associated with one of thecustomer devices currently in contact to the POS system. Theestablishment of the communications link may already be performed whilethe customer is waiting in line and does not need to await a uniqueidentification, thereby yielding a short check-out time. Short check-outtimes are desirable, as they increase the efficiency of a POS, therebyreducing costs and increasing customer satisfaction.

It is a further advantage that possible race conditions are avoidedsince multiple customers are allowed to access the payment systemsimultaneously, and the correct customer device is subsequentlyidentified. Consequently, the techology provides a reliable method ofperforming wireless transactions.

The term customer device comprises any electronic device which may becarried by the customer, attached to a shopping cart, or the like.Examples of customer devices comprise mobile terminals, such as mobiletelephones, Personal Digital Assistants (PDA), communicators, otherhand-held computers, or the like. As the customer device may comprisesecurity sensitive information, such as credit card numbers, digitalsignatures, PIN-codes, or the like, the customer device is, preferably,a personal device or a device which may be personalised, e.g. byinserting a personalised module, e.g. a storage and/or processing modulesuch as a smart card, a SIM card or the like. It is advantageous to usea customer's personal device, e.g. the customer's mobile telephone orPDA, as a customer device, since the customer is familiar with the useof the device and since he trusts the device, thereby ensuring anefficient use of the device. In the following the customer device willalso be referred to as a PTD (Personal Trusted Device).

The transaction system may be any electronic system for performingelectronic transactions, for example an electronic POS system, a cashregister, a vending machine, a check-out system, a check-in system, anetwork of POS systems connected to a central server computer via acomputer network, or the like. The transaction system may be operated bya shop assistant or the like, or it may be an automated self-servicesystem, such as a vending machine, a check-out system in a self-scanscenario, or the like.

Correspondingly, the transaction may comprise the transfer of money fromone account to another, e.g. in order to pay for goods or services in aretail store.

It is an advantage of the technology, that it allows customers to use acustomer device to instead of a traditional credit card, otherwiseleaving the customer's shopping experience unchanged. Examples of othertransactions include the transfer of data, the use of tokens, e.g. bonusor credit points, etc.

The wireless communications links may be based on any suitable wirelesscommunications technology, e.g. radio-based communication orcommunication using other electromagnetic radiation, e.g. infraredradiation. Preferably the communications links are short-rangecommunications links operating in a sufficient range around thetransaction system. Examples of known communications standards for shortrange wireless communications comprise Bluetooth and IrDA (Infrared DataAssociation). This has the further advantage that the communicationslinks do not have to be established via any network provider, and thatthe communication only requires little power provided by the customerdevice.

Preferably, the communication utilises one or more suitablecommunications protocols and/or standards. Examples of such standardsinclude Transmission Control Protocol (TCP), Internet Protocol (IP),User Datagram Protocol (UDP), Wireless Application Protocol (WAP),Wireless Transport Layer Security (WTLS), Wireless Identity Module(WIM), Wireless Public Key Infrastructure (WPKI), Mobile electronicTransaction (MeT) initiative, Hypertext Markup Language (HTML),Extensible Markup Language (XML), Hypertext Transfer Protocol (HTTP),Secure Hypertext Transfer Protocol (HTTPS), Secure Sockets Layer (SSL),etc.

A communications link is already established when it is the customer'sturn to pay, thereby saving considerable time. Furthermore, the waitingin line appears shorter as the customer is occupied during the time ittakes to initiate the payment process.

Furthermore, the waiting time may be further utilised to perform othertasks such as identifying prior sales performed with that customerdevice, credit checking, etc. As these tasks may be performed prior tothe customer approaching the counter, the actual time needed for theactual check-out is further reduced.

In a preferred example embodiment, the step of identifying the firstcustomer device further comprises the steps of

-   -   assigning respective identifiers to each of the number of        customer devices by the transaction system, a first identifier        being assigned to the first customer device;    -   transmitting the respective identifiers from the transaction        system to the corresponding customer devices via the        corresponding wireless communications links; and    -   using the first identifier to identify the first customer device        carried by the selected customer.

Consequently, when a communications link is established, an identifieris transmitted to the customer device, preferably while the customer isstill waiting in line. As the identifier does not need to uniquelyidentify a transaction but only identify a customer device among thecustomer devices which are currently connected to the POS, theidentifier may be rather short, preferably less than five characters.

In a further preferred example embodiment the step of using the firstidentifier to identify the first customer device comprises the steps of

-   -   presenting the first identifier to the selected customer by the        first customer device; and    -   receiving a first input by the transaction system from a user of        the transaction system, the first input being indicative of the        first identifier.

This has the advantage that it provides a fast way of selecting theright customer. At the same time the anonymity of the customer ispreserved as no information about the customer, such as name, telephonenumber, or the like, needs to be communicated between the salesassistant and the customer. Furthermore, no extra equipment, such as ascanner for scanning in a telephone ID, or the like, is necessary,thereby providing a simple, efficient and reliable way of identifyingthe correct customer device.

The identifier may be presented to the customer via a display of thecustomer device, or by another suitable output device, e.g. audible.

The identifier may be directly entered into the transaction system bythe customer, e.g. via a keyboard, a keypad, or by selecting a numberfrom a list of numbers which may be displayed on a display of thetransaction system. In another embodiment, the identifier may betransmitted from the customer device to the POS, e.g. via infrared orradio-based transmission. In a scenario with a shop assistant operatinga POS system, the identifier may be communicated to the shop assistantand then be entered by the shop assistant. For example, the shopassistant may simply ask the customer for his identifier.

In a preferred example embodiment, the first identifier is a sequence ofalphanumeric characters comprising digits and/or letters. Preferably,the sequence comprises less than five alphanumeric characters. In manyapplications, even two digits or characters may be sufficient.Consequently, the identifier may be easily communicated and/or entered,and the likelihood of errors due to misunderstandings and/or theentering of incorrect identifiers is reduced.

In a further preferred example embodiment, the first identifier has alength determined by the transaction system on the basis of the numberof customer devices having established a wireless communications linkwith the transaction system. Consequently the length of the identifiermay be optimised depending on the number of customers currently in line,thereby ensuring a unique identification of customer devices with theshortest possible identifiers. For example, while in peak hours two oreven three characters and/or digits may be needed, in off-peak hours aone-digit identifier may be sufficient to distinguish differentcustomers.

In another preferred example embodiment, the method further comprisesthe steps of

-   -   storing in a storage medium a set of customer data items in        relation to a set of device data items, the set of customer data        items being indicative of a set of registered customers and the        set of device data items being indicative of a corresponding set        of customer devices;    -   presenting to a user of the transaction system selected ones of        the set of customer data items related to the customer devices        having established respective wireless communications links;    -   receiving a second input by the transaction system from the user        of the transaction system, the second input being indicative of        a selected one of the presented customer data items.

Consequently, customer data, such as name, address, phone number, apassword, a picture, or the like, may be stored by the transactionsystem together with an identification, e.g. a phone number, a Bluetoothdevice address, or the like, of one or more customer devices related tothe customer. Hence, as the stored customer data is used to associatethe customer who is ready to pay with a customer device, it is anadvantage of this embodiment that no manual inputting of an identifieris necessary, thereby further reducing the likelihood of errors.Furthermore, as additional information, such as a picture, about thecustomer is used to identify the customer device, extra security may beachieved. For example, if the shop assistant selects the customer from alist of customers via a picture, the likelihood of an unauthorisedperson misusing the customer device is further reduced.

In a further preferred example embodiment, the step of presentingselected ones of the set of customer data items further comprises thestep of selecting a subset of the number of customer devices based onadditional information about the customer devices. This is particularlyadvantageous in situations with many cash registers in the vicinity ofeach other and/or a large number of customers being ready to pay fortheir goods. In such a situation, a large number of customer devices mayhave established communication links to the transaction system, therebycausing the list of customer data items presented to the cashier to berather long. Hence, a limitation to relevant customer data items makesit easier for the shop assistant to select the right customer, therebyincreasing the efficiency of the method. Such a limitation may, forexample, comprise a limitation to customer devices within a certaindistance from the cash register. Correspondingly, the additionalinformation may comprise reception characteristics of at least theestablished wireless communications links, e.g. by measuring orestimating the distance of the customer devices from the POS.

In another further preferred example embodiment, the step of presentingselected ones of the set of customer data items further comprises thestep of presenting the selected customer data items in a predeterminedorder based on additional information about at least one of the customerdata and the customer devices. Consequently, the presented list ofcustomer data items may be ordered such that the most likely customersare on top of said list. Again, this provides a particularly efficientway of identifying the correct customer device, especially in situationswith a large number of customers.

The additional information may comprise reception characteristics of atleast the established wireless communications links, e.g. by measuringor estimating the distance of the customer devices from the POS andpresenting the closest devices on top of a list. Alternatively, othertypes of information may be used, e.g. the type of goods purchased inrelation to previously purchased items. If, for example, a customer haspurchased diapers and baby food and if historic information about thepurchase preferences of customers is stored in the transaction system, afamily father may be placed higher on the list than somebody who usuallydoes not purchase diapers, etc.

In yet another preferred example embodiment, the transaction includes atransfer of a predetermined amount from a customer account to arecipient account, and the method further comprises the steps of

-   -   transmitting a second data signal indicative of the        predetermined amount from the transaction system to the first        customer device via the corresponding wireless communications        link;    -   receiving a third input from the selected customer to the        wireless customer device, the third input being indicative of an        authorisation to transfer the predetermined amount from the        customer account to the recipient account;    -   transmitting the first data signal in response to the third        input; and    -   initiating the transfer of the predetermined amount by the        transaction system in response to the received first data        signal.

It provides a secure and efficient method of initiating a transaction.As the customer is required to authorise the transaction using hiscustomer device after the customer device has been associated with him,the likelihood of erroneous transactions or misuse is further reduced.

In yet another preferred example embodiment, at least a first one of therespective wireless communications links is a Bluetooth link. Bluetoothis a short-range RF based communications technology operating at 2.4 GHzand with a range of currently up to approx. 10 m. However, futureversions of Bluetooth are expected to operate at larger distances, e.g.100 m. Furthermore, it is an advantage that Bluetooth is not directionsensitive and that it provides the possibility of creating ad-hocconnections between Bluetooth devices without the need of userinteraction. Consequently, wireless communications links may beestablished automatically or in response to a user action, while thecustomer is waiting in line, even in a certain distance from the POS.

A system for processing a transaction request, includes a transactioncomponent and a number of customer devices carried by respectivecustomers. A transaction request is approved by transmitting a firstdata signal from a customer device to the transaction component via awireless communications link.

The system further includes:

-   -   communications means for establishing respective wireless        communications links between the transaction component and        corresponding ones of the number of customer devices; and    -   means for identifying a first one of the number of customer        devices having established respective wireless communications        links as being a customer device carried by a selected one of        the customers.

In a preferred example embodiment,

-   -   the means for identifying a first one of the number of customer        devices comprise first processing means adapted to assign        respective identifiers to each of the number of customer        devices, a first identifier corresponding to the first customer        device;    -   the communications means is adapted to transmit the respective        identifiers from the transaction component to corresponding        customer devices via the corresponding wireless communications        links; and    -   the means for identifying a first one of the number of customer        devices comprises means for using the identifier to associate        the selected customer with the first customer device.

In a further preferred example embodiment, the means for using theidentifier to associate the selected customer with the first customerdevice comprises

-   -   first output means for presenting the first identifier to the        selected customer; and    -   first input means for receiving a first input from a user of the        transaction component, the first input being indicative of the        first identifier.

In another preferred example embodiment, the system further comprises

-   -   a storage medium adapted to store a set of customer data items        in relation to a set of device data items, the set of customer        data items being indicative of a set of registered customers and        the set of device data items being indicative of a corresponding        set of customer devices;    -   second output means for presenting selected ones of the set of        customer data items to a user of the transaction component; and    -   second input means for receiving a second input from the user,        the second input being indicative of a selected one of the        presented customer data items.

In yet another preferred example embodiment,

-   -   the transaction request includes a request to transfer a        predetermined amount from a customer account to a recipient        account;    -   the communication means is adapted to transmit a second data        signal indicative of the predetermined amount from the        transaction component to the first customer device via the        corresponding wireless communications link;    -   the first customer device comprises third input means for        receiving a third input from the selected customer, the third        input being indicative of an authorisation to transfer the        predetermined amount from the customer account to the recipient        account;    -   the communication means is further adapted to transmit the first        data signal in response to the third input; and    -   the system further comprises second processing means adapted to        initiate the transfer of the predetermined amount by the        transaction component in response to the received first data        signal.

The technology further relates to a customer device for processing atransaction request from a transaction system, a transaction requestbeing approved by transmitting a first data signal from the customerdevice to the transaction system via a wireless communications link; thecustomer device comprising

-   -   communications means for establishing a wireless communications        link between the customer device and the transaction system; and    -   means for assisting the transaction system in identifying the        customer device among a number of customer devices having        established respective wireless communications links as being a        customer device carried by a selected customers.

The technology further relates to a transaction system for processing atransaction request to be approved by a first customer device bytransmitting a first data signal from the first customer device to thetransaction system via a wireless communications link; the transactionsystem comprising

-   -   communications means for establishing respective wireless        communications links between the transaction system and a number        of customer devices; and    -   means for identifying the first customer device among the number        of customer devices having established respective wireless        communications links as being a customer device carried by a        selected customer.

The technology further relates to a computer program comprising programcode means for performing all the steps of the method described aboveand in the following when said program is run on a computer. Preferably,the computer program is embodied on a computer-readable medium.

The term input means may comprise a keyboard, a keypad, a button and oran arrangement of buttons, a touch screen, a pointing device, such as amouse, a trackball, a touch pad, a digital pen, or the like the terminput means may further comprise other forms of man-machine interfaces,such as a voice interface, or the like.

The processing means may comprise a microprocessor, anapplication-specific integrated circuit, or another integrated circuit,a smart card, a general purpose computer adapted by suitable software,or the like.

The term output means may comprise a display device, such as a monitor,a liquid crystal display, a cathode ray tube to display a graphical userinterface, or the like. Alternatively or additionally, the output meansmay comprise an audible output device, such as a sound card and/or aspeaker.

The term storage medium may comprise any computer-readable medium, suchas magnetic tape, optical disc, digital video disk (DVD), compact disc(CD or CD-ROM), mini-disc, hard disk, floppy disk, ferro-electricmemory, electrically erasable programmable read only memory (EEPROM),flash memory, EPROM, read only memory (ROM), static random access memory(SRAM), dynamic random access memory (DRAM), synchronous dynamic randomaccess memory (SDRAM), ferromagnetic memory, optical storage, chargecoupled devices, smart cards, etc.

The term communications means comprises a transmitter and/or a receiveradapted to establish and transmit/receive data via the wirelesscommunications links.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 a shows a schematic view of a first example embodiment of asystem;

FIG. 1 b shows a flow diagram of a method according to an exampleembodiment;

FIG. 2 shows a flow diagram of a first example embodiment of the step ofidentifying the customer device of the customer whose turn it is to pay;

FIG. 3 schematically illustrates a number of screen pictures displayedon the display of the customer device during the process of paying foritems with a customer device;

FIG. 4 illustrates a flow diagram of a second example embodiment of thestep of identifying the customer device of the customer whose turn it isto pay;

FIG. 5 shows the different actors and processes related to a system;

FIG. 6 shows a schematic view of a system according to a preferredexample embodiment; and

FIG. 7 a-d illustrate messages communicated between the components of asystem according to an example embodiment.

DETAILED DESCRIPTION

FIG. 1 a shows a schematic view of a first embodiment of a system. Thetransaction system 100 comprises a point of sale (POS) system 101 with adisplay 101 a and a keyboard/keypad 101 b. For example, the POS maycomprise a cash register with a scanning station for the scanning ofbarcodes on the goods, or other means for registering the goods, e.g. akeyboard, keypad or other input means for manually inputting pricesand/or product IDs, means for registering product information stored ona microchip, etc. The POS system 101 is connected to a server computer104 with a central processing unit (CPU) 104 a and a storage medium 104b. The server computer 104 manages the transactions and it is furtherconnected to a Bluetooth transceiver 102. Preferably, the Bluetoothtransceiver 102 operates in an inquiry mode. In this mode thetransceiver constantly or periodically attempts to discover and identifycustomer devices within its range in order to establish Bluetoothconnections to the customer devices T1 -T3 carried by customers in theproximity of the transceiver 102. In the example of FIG. 1 a thecustomers A-D are in the proximity of the POS system 101, and customersA,B, and D carry PTDs T1, T2 and T3, respectively. The PTDs T1-T3 eachcomprise a display T1 a T3 a, a keypad T1 b T3 b, and a Bluetoothtransceiver (not shown), and they are adapted to establish respectiveBluetooth connections 105-107 to the transceiver 102. The customerdevices may be in a discoverable mode and ready to establish a Bluetoothconnection to the transceiver 102. In another embodiment, the customerdevice may not permanently be ready to accept the establishment of aBluetooth connection but rather require an input from the customer inorder to initiate the attempt to establish a connection. For example,the customer may press a button on the customer device or select acorresponding menu item. In the example of FIG. 1 a, it is customer A'sturn to pay, and he has placed an item 103 on a counter at the POSsystem 101. Furthermore, in the example of FIG. 1 a, customer A carriesa PTD T1 which has established a Bluetooth link to the transceiver 102.

FIG. 1 b shows a flow diagram of a method according to an exampleembodiment. The flow diagram in FIG. 1 b refers to the systemillustrated in FIG. 1 a. When a customer A approaches the check-outcounter of the POS system 101, he places, in step 111, the item 103 hewishes to purchase on a counter and, in step 112, the price of the itemis entered into the POS system 101. For example, this may be done by ashop assistant, e.g. manually or by scanning a bar code placed on theitem. In step 113 the transceiver 102 has established communicationslinks to the customer devices T1-T3 which are currently in the proximityof the transceiver 102. Preferably, this is done asynchronously to andindependently of the step 112 of entering the price of the item 103,such that the server computer 104 at any time maintains a list of PTDswhich are currently connected to the transceiver 102. When the customerA wishes to pay for the item 103 with his PTD, in step 114, the shopassistant identifies customer A's PTD T1 from the list of PTDs which arecurrently connected to the POS system 101. Once the correct PTD isidentified, the payment may be handled in step 115 by the servercomputer 104 and the PTD T1.

During a traditional credit card payment in a retail store, the customerslides his or her card through the card reader associated with a cashregister. Besides transferring the customer's credit card information tothe card reader, this also serves to uniquely associate the customerwith the amount to be paid. For a brief moment the customer is actuallyin physical contact with the POS, as he is holding his card, the card istouching the card reader, and the card reader is connected to a specificPOS. Assuming that there is only a single card reader per POS and thatonly a single card fits into the card reader at a time, the result isunique association.

When a PTD is used instead of a credit card, the conditions whichguarantee unique association are violated, since there is no physicalcontact between the customer and the POS, and since several customerswith PTDs may be connected to the same POS simultaneously. As a result,situations may arise where it is unclear which customer is paying forwhat. As described above, this problem is solved according to theinvention.

FIG. 2 illustrates a flow diagram of a first embodiment of the step ofidentifying the customer device of the customer whose turn it is to pay.The flow diagram in FIG. 2 is arranged in three columns labelled PTD, Svand POS, thereby indicating which steps are performed by the PTD T1, theserver computer 104, and the POS system 101, respectively. Initially, instep 201, the customer A initiates the identification and paymentprocess, e.g. by pressing a button on his PTD. In the subsequent step202, the PTD sends a corresponding request to the server computer. Inresponse to this request, in step 203, the server creates a data recordin a database 210 corresponding to a new transaction. The servercomputer further generates a number or another identifier and associatesit to the new transaction. The number may for example be a two-digitnumber, selected such that at any time there is only one opentransaction stored in the database 210 with that number associated toit. In the subsequent step 204, the generated number is sent to the PTDwhere it is displayed (step 205). The above steps 201-205 may beperformed while the customer is still waiting in line before it actuallyis his turn to pay. After displaying the number, the PTD waits (step206) for the server computer to transmit an electronic contract. Hence,several PTDs may be waiting at the same time, since several customerswaiting in line may have initiated the payment process and may havereceived respective numbers. For each of these PTDs there is a datarecord representing an open transaction in the database 210. When it isthe customer A's turn to pay and his goods are registered in the POSsystem, he indicates to the shop assistant that he wishes to pay withhis PTD and communicates the number displayed on his display to the shopassistant. In step 207, the shop assistant enters the number in the POSsystem, and the POS system communicates the number to the servercomputer. In the subsequent step 208, based on the received number, theserver computer retrieves the corresponding transaction information fromthe database 210, including the identification of the PTD T1 and thecorresponding communications link. Furthermore, the server computergenerates a contract including the total price of the registered itemsand sends the electronic contract to the PTD T1, which receives thecontract in step 209. Subsequently, an electronic transaction may beinitiated between the identified PTD T1 and the server computer basedupon the electronic contract. This will be described in greater detailin connection with FIGS. 3, 6 and 7 a-d.

It is understood that other ways of presenting the number to thecustomer may be employed, e.g. an audible presentation via the speakerof the phone.

It is further understood that other ways of entering the number into thePOS system may be utilised. For example, the customer may enter thenumber directly into an automated POS system without interacting with asales assistant, e.g. via a keypad, touch screen, speech recognition, orthe like.

Alternatively, a shop assistant selects a number from a list of numbers,e.g. by pointing with a pointing device on a list of items displayed ona display, or by keying in the number via a keypad.

FIG. 3 schematically illustrates a number of screen pictures displayedon the display of the customer device during the process of paying foritems with a customer device according to the invention. When acommunications link between the vending system and the PTD isestablished, a welcome screen 301 may be displayed on the PTD, e.g.comprising a welcome message, a logo and/or the like. The welcome screenmay also trigger an audible message, e.g. a beep sound, in order tocatch the customer's attention. Subsequently, e.g. after a predeterminedperiod of time, the welcome screen is replaced by a main menu 302, whichmay comprise a list of selectable items, e.g. as WAP links or the like.The list may comprise a “pay” item which may be selected when thecustomer wishes to use the PTD for paying. Other items may compriseinformation about special offers or other local information about thestore. If the customer selects the “pay” item, e.g. by using thenavigation keys of the keypad of the PTD, a request is sent to thevending system as described in connection with FIG. 2. In response tothat request, the PTD receives a number which is displayed on screen303. If the communication fails, an error message 309 may be displayedallowing the customer to return to the main menu via a correspondinglink. When the PTD has received an electronic contract from the vendingsystem, e.g. according to step 209 in FIG. 2, a screen picture 304 withthe total amount is displayed asking the customer to confirm thepayment. If the customer confirms, e.g. by pressing a “YES” button onthe PTD, a screen 305 may be displayed, allowing the customer to selectone of a number of alternative credit cards. When the customer hasselected a card, a screen 306 is displayed asking the customer to entera corresponding PIN code. If the customer does not have several cards tochoose from, the screen 306 may be displayed directly after screen 304.Furthermore, in connection with the above screens 304-306, the customerhas the possibility to cancel the payment, e.g. by pressing a “NO” or“CANCEL” button of the PTD. In this case a screen 310 is displayed whichinforms the customer that the transaction has been cancelled and whichallows him to return to the main menu 302. After entering the PIN codevia the keypad of the PTD in connection with screen 306, the PIN code isverified. If the PIN code was incorrect, the customer is informed aboutthe error by displaying a corresponding message 311, and he may returnto the screen 306 to try again. If he failed a predetermined number oftimes, e.g. 4 times, the card may be blocked and payment cancelled. Thecustomer may be informed about this, e.g. by the screen 312-313 allowinghim to return to the main menu 302. If the PIN code was correctlyverified, the transaction is initiated. While the actual transaction isin progress a corresponding message 307 may be displayed. The stepsperformed during the actual transaction will be described in connectionwith FIGS. 7 a-d. After successful completion of the transaction, acorresponding acknowledgement 308 is displayed and the customer mayreturn to the main menu 302. If the transaction has failed for somereason, e.g. due to a communications error, or the vending system beingdown, a corresponding error message 314 is displayed instead.

FIG. 4 illustrates a flow diagram of a second embodiment of the step ofidentifying the PTD of the customer whose turn it is to pay. Again, theflow diagram in FIG. 4 is arranged in three columns labelled PTD, Sv andPOS, indicating which steps are performed by the PTD T1, the servercomputer 104, and the POS system 101, respectively. As in the embodimentdescribed in connection with FIG. 2, the customer A initiates theidentification and payment process in step 401, e.g. by pressing abutton on his PTD. In the subsequent step 402, the PTD sends acorresponding request to the server computer. In response to thisrequest, in step 403, the server creates a data record in a database 411corresponding to a new transaction, and sends a reply to the PTD,causing the PTD to wait, in step 404, for the server computer totransmit an electronic contract. In contrast to the embodiment of FIG.2, no number is transmitted for display on the display of the PTD.Again, the above steps 401-404 may be performed while the customer isstill waiting in line before it actually is his turn to pay.

When the shop assistant at the POS system has registered the items ofcustomer A and customer A has indicated that he wishes to pay via hisPTD, the shop assistant initiates (step 405) the payment process at thePOS system, e.g. by selecting a “pay by PTD” option on a menu displayedin the user interface of the POS system, by pressing an appropriatebutton, or the like. The POS system sends a corresponding request to theserver computer which, in step 406, retrieves a list of currently opentransactions from the database 411. The data record corresponding toeach transaction comprises a unique ID of the corresponding PTD. Forexample, the ID may be received from the PTD during the establishment ofthe communications link. According to this embodiment of the invention,the database further comprises information about registered customers,such as the customer's name, picture or other relevant informationtogether with the IDs of one or more PTDs owned by the customer. Thisinformation may be acquired and stored in connection with an initialregistration of the customer. Hence, the list of transactions retrievedin step 406 comprises a list of customers who are currently ready to payusing their PTD. In the subsequent step 407 the retrieved list ispresented to the shop assistant via the display of the POS system, andthe shop assistant may use the list to identify the customer in front ofhim (step 408). For example, if the list contains a name, the cashiermay simply ask the customer for his name, receive the answer and makethe appropriate selection, e.g. via a pointing device, a touch screen ora keyboard/keypad of the POS system. If the list contains pictures, thecashier may make a selection by looking at the customer, comparing thecustomer with the pictures on the list and selecting the appropriatepicture. Based on the shop assistant's selection, the server computerretrieves the corresponding transaction information and generates acorresponding electronic contract in step 409. The electronic contractis subsequently transmitted to and received by the waiting PTD in step410. Subsequently, an electronic transaction may be initiated betweenthe identified PTD and the server computer based upon the electroniccontract. This will be described in greater detail in connection withFIGS. 3, 6 and 7 a-d.

Alternatively or additionally, if no customer is registered for a PTD orno customer information is available at the transaction system, a numbermay be sent to that PTD as in the embodiment of FIG. 2.

It is noted that the list of transactions which is presented to thecashier may be limited to records corresponding to clients which are ina predetermined area. For example, this may be achieved by shielding ofthe communications signals or additional measurements, e.g. by usingmultiple radio transceivers, GPS measurements, etc. Alternatively oradditionally, the list may be prioritised, e.g. by comparing theregistered items with the typical types of goods purchased by thecustomers during previous visits. Preferably, the list is only bepresented, if multiple customers are accessing the payment system and aselection is necessary.

FIG. 5 illustrates the different actors and processes related to asystem according to an example embodiment FIG. 5 also illustrates byarrows which actors are involved in which processes or use cases. Theactors include

-   -   the customer 501, i.e. the person shopping and paying using a        customer device according to the invention,    -   the issuing agent 503, i.e. the agent issuing the electronic        credit cards, e.g. via the bank of the customer 501,    -   the merchant 502, i.e. the company offering a payment service        according to the invention,    -   the acquirer 505, i.e. the bank of the merchant 502, and    -   the collector 504, i.e. a company acting as intermediate between        merchants and acquirers.

The different use cases related to a system according to an embodimentof the invention comprise:

Customer Registration 506: The primary job of the issuing agent 503 isto provide customers 501 with electronic credit cards embodied aselectronic certificates. This is referred to as customer registration.Preferably, the customer 501, the merchant 502, and the collector 504have a number of keys and certificates. For example, all parties mayhave been issued or have generated two key pairs, an authentication keypair and a signature key pair, e.g. according to a standard encryptionalgorithm such as the RSA encryption and authentication system. Theauthentication key pair is used to establish encrypted connectionsbetween the three parties. The signature key pair is used to digitallysign transactions in order to achieve non-repudiation. Furthermore, eachparty may have been issued certificates authenticating their publicauthentication and signature keys. The authentication certificates maybe exchanged between the protocol stacks of two parties when a secureconnection is established. The signature certificates enable the partiesto perform specific actions: The customer's signature certificaterepresents an electronic credit card. It enables the customer todigitally sign payment contracts issued by the merchant. The merchantand collector may verify the authenticity of the public signaturecertificate to guard against fraud. The merchant's signature certificateindicates that the merchant has been authorised to receive payment froma PTD. The merchant system uses this certificate to sign requests madeto the collector, thereby enabling the collector to verify themerchant's identity and privileges. The collector's certificate is usedby the merchant to verify authorisation and capture response messages.This enables the collector to produce legally binding replies to themerchant. Preferably, in addition to the certificates mentioned above,the parties are issued two trusted root certificates: The RootAuthentication (RA) and Root Signature (RS) certificates. The RAcertificate is a self-signed certificate containing the public key ofthe certificate authority, which issued the other authenticationcertificates. The RA certificate is used to verify the authenticity ofthe other authentication certificates. The RS certificate is aself-signed certificate containing the public key of the certificateauthority, which issued the other signature certificates. The RScertificate is used to verify the authenticity of the other signaturecertificates. The collector verifies the validity of both customer andmerchant certificates, including revocation checking. Hence, themerchant does not need to perform revocation checks of customercertificates. If one assumes that collector certificates are notrevoked, the merchant system does not need to perform any revocationchecks. In this case, revocation lists are not distributed, but simplymaintained by the collector. The PTD does not receive signed content,hence it has no need for an RS certificate. During customerregistration, the issuing agent 503 verifies that the customer's publicsignature key corresponds to the customer's private signature key andthat the customer is who he or she claims to be. Based on this, theissuing agent creates a certificate containing the public key, customerID, and account information. The certificate is issued to the customer,who stores it in the PTD, e.g. as an URL.

Revocation 510: Because PTDs may be stolen or misused, the issuing agent503 has the option to revoke customer certificates. Similarconsiderations apply for merchant certificates as described below.Revocation is performed by informing the collector 504 that a certaincertificate is no longer valid. The revocation of customer certificatesmay be done on behalf of the customer 501.

Merchant Registration 511: The purpose of merchant registration is toenable merchants 502 to receive electronic payments according to theinvention. For this purpose, the collector 504 issues a merchantcertificate containing the merchant's public signature key and themerchant ID.

Authorisation 509: During payment transactions, the merchant 502requests payment authorisation from the collector 504. If authorisationis granted, the merchant 502 receives a guarantee that money can betransferred from the customer 501 to the merchant 502.

Capture 512: The collector 504 acts as a front-end to a financialnetwork of participating banks. As such, the primary function of thecollector 504 is to resolve the security based on a public keyinfrastructure (PKI) before forwarding transactions to the acquirer 505.In line with existing credit card processing procedures, the collector504 “collects” transactions from the merchant (during authorisation)into batch jobs, which are exchanged with the acquirer 505 on a regularbasis. The exchange of batch jobs is referred to as “capture”.Preferably, the merchant 502 initiates capture processing at the end ofthe business day. It should be noted that no money is moved betweenaccounts before the capture phase.

Local Merchant Services 508: Preferably, the customer 501 has access tovarious localised services, e.g. WAP services, provided by the merchant502,. Examples of such services include special offers, e.g.advertisements, directions, e.g. to the physical placement of certaingoods, and information on goods and services.

Local Bank Services 507: Preferably, the customer 501 has access tovarious services, e.g. WAP services, provided by the acquirer 505 orissuing agent 503. Examples of such services include information aboutspecial offers, e.g. advertisements to cardholders, exchange rates,balance information of the customer's accounts, and information aboutother services.

It should be noted that the above actors and use cases are examples, anda system may correspond to other actors and/or use cases within thescope of the invention.

FIG. 6 shows a schematic view of a system according to a preferredexample embodiment. The system is distributed across three sites: Themerchant site 601, e.g. a retail store, the collector site 602, and theacquirer site 603. At the merchant site 601, one or more POS systems 601are logically associated with a Bluetooth network access point 605. Anetwork access point comprises a Bluetooth transceiver and providesaccess to the local area network (LAN) 610 via the wireless Bluetoothnetwork 604. When a customer approaches the POS system 606, a Bluetoothconnection is established, via the wireless Bluetooth network 604,between the customer's PTD 603 and the network access point 605. via theLAN 610, the network access point is connected with an applicationserver 608 running a payment application software. Hence, the customergains access to the payment application via the Bluetooth connection andthe network access point 605. The application server 608 is alsoconnected to the POS system 606 via the LAN 610. The payment applicationrunning on the server 608 receives the amount to be paid from the POSsystem 606 via the LAN, and presents this amount to the customer via thePTD 603. The customer digitally signs an agreement to pay this amount,and this signature is returned to the payment application on the server608. The application, in turn, requests payment authorisation from thecollector system 614. The application server is connected to thecollector system 614, via a communications system, e.g. via ISDN routers611 and a telephone network 612 or through a firewall 609 via theInternet 615. Preferably, the ISDN routers act as firewalls in theformer case. The choice of connection may depend upon the merchant'sexisting equipment. The collector system 614 is further connected to theacquirer system 618, preferably via the Internet 615. Preferably, boththe collector system 614 and the acquirer system 618 are protected byfirewalls 616 and 617, respectively. Preferably, WTLS is used betweenthe PTD and the merchant system, whereas SSL is used between themerchant and collector systems.

FIGS. 7 a-d show schematic views of message flows between the componentsof a system according to an embodiment of the invention, e.g. themessages communicated during the processing of a transaction between thePOS system 606, the server computer 608, the collector system 614, andthe customer device 603 shown in FIG. 6. A transaction is represented bya data record in a database maintained by the payment application on theserver computer. A transaction may go through a number of states duringits lifecycle, including the following states:

-   Open: The customer has chosen to pay using the PTD. Multiple    customers may be queued in the system, waiting to pay.-   Active: The transaction has been tied to a purchase and the total    amount to be paid is known. Preferably, only one transaction can be    active per POS.-   Offered: The customer has been issued a payment contract to sign.    Preferably, only one transaction may be offered per POS.-   Signed: The customer has signed the payment contract and it has been    forwarded to the collector. Preferably, only one transaction may be    signed per POS.-   Authorised: The collector has authorised the payment. Preferably,    only one transaction may be authorised per POS.-   Completed: The POS system has written a paper receipt to the    customer.

In addition to the above states, the transaction may enter additionalstates, e.g. error states.

In FIGS. 7 a-d, vertical lines correspond to the different components ofthe system and illustrate a logical flow from top to bottom. Arrowsbetween columns indicate messages communicated between the correspondingcomponents, where solid arrows correspond to messages, dashed arrowscorrespond to replies to messages. Dotted arrows correspond to updatesand/or queries of the database 704 where the transactions are storedtogether with their respective status and identified by respectivetransaction IDs. The vertical lines further comprise boxes illustratingprocesses being performed by the corresponding components. Arrowsstarting and ending at the same column correspond to control flowswithin the same process, such as loops.

In FIG. 7 a the columns labelled PTD, Col, and POS correspond to thecustomer device, the collector system and the POS, respectively. Theserver computer of the vending system is represented by two columnslabelled Sv1 and Sv2, corresponding to two server processes of thepayment application running on the server computer which are responsiblefor the communication with the PTD and the POS system, respectively. Thetwo server processes will also be referred to as PTD servlet SV1 and POSservlet Sv2, respectively, as they may be implemented as Java servlets.The two server processes may communicate via updates of the database 704hosted by the server computer. Alternatively, the database 704 may bephysically located on a different computer, and/or the two processes maybe executed on separate computers or they may be implemented by a singleprocess.

In the example of FIG. 7 a, a customer has picked out a number of goodsand has reached the POS system. The goods have been registered by thecashier in the POS system, and the total amount to be paid is known.Furthermore, a Bluetooth link has been established between the PTD andthe network access point, e.g. using standard Bluetooth mechanisms. Whenthe customer selects “Pay” on his PTD (step 701), the PTD sends apayment initialisation request 702 to the PTD servlet Sv1. For example,the request 702 may be a WSP GET request, e.g.“http://someserver/servlets/PTDServlet”, where the PTD provides no querypart in the request URL. This indicates that a new transaction isrequested. In step 703, the servlet Sv1 creates a new, open paymenttransaction in the database. Preferably, the transaction is related to atransaction ID which, for example, may comprise a 14-digit integercontaining a 4-digit year, a 2-digit month, a 2-digit day, and a 6-digitserial number. An example of such an ID is “2001012123456.” The ID ofthe open transaction is returned to the PTD as part of a responsemessage 705, causing the PTD to enter a polling loop 708. In this loop,the PTD queries the application at regular intervals for a contract,e.g. every second, as indicated by the request 706 and the response 707.For example, the request 706 may be a WSP GET request comprising thetransaction ID in the query part of the URL. Following the example ofthe above transaction ID, an example of such an URL may be“http://someserver/servlets/PTDServlet?id=20001012123456.” While in thepolling loop 708, a message may be displayed on the PTD telling thecustomer to wait. If the payment set-up requires the customer toverbally identify himself to the cashier, a number may be displayed aspart of the message, e.g. as illustrated by the message 303 in FIG. 3.This number may be transmitted as part of the response message 705, e.g.appended to the transaction ID.

Once the cashier initiates the payment process via the POS system, e.g.by pressing a “pay using phone” button on the POS system, a HTTP GETrequest 712, e.g. “http://someserver/servlets/CashRegisterServlet/trans”is sent to the POS servlet Sv2, causing the POS servlet Sv2 to look upthe currently open transactions in the database 704 (step 711).Preferably, the POS system keeps polling the servlet Sv2 until there isa response. In one embodiment, the servlet Sv2 may return a list of opentransaction Ids with associated customer descriptions and/or thedisplayed queue number.

The merchant system may use various techniques to limit the number ofcustomers on the list, e.g. shielded Bluetooth coverage. The nature ofthe customer description depends on whether the merchant system hasaccess to the customer's name or similar identifying information.Alternatively or additionally, the system may assign a queue number tothe transaction and use this a description, as was described above. Thelist may be displayed to the cashier, who selects the right customer.Alternatively, in the case of the queue number, the cashier may enterthe queue number. The POS system then enters a polling loop 717 where itasks for payment confirmation by sending a confirmation request 714 tothe POS servlet Sv2 of the payment application. For example, theconfirmation request 714 may comprise the transaction ID, a total amountand VAT, e.g.“http://someserver/servlets/CashRegisterServlet/trans?id=20001023123456&amount=149,99.”While in this loop, the POS will query the servlet for paymentconfirmation at regular intervals (e.g. every second), as illustrated bythe message-response pair 714 and 716 and the loop 717. The servlet Sv2saves the received amount in the database 704 and updates the state ofthe transaction to “active” (step 719).

At the next poll of the polling loop 708 of the PTD, the PTD servlet Sv1discovers the active state of the transaction in the database. Based onthe amount, it issues a contract to the PTD (response message 720),records the contract and updates the state of the transaction to“offered” (step 710). For example, the contract response 720 maycomprise the transaction ID followed by the contract text. Preferably,the contract text should be in plain text and it should follow apredetermined syntax to ensure that the collector system is able toparse it. An example of such a syntax is

-   contract ::=<amount> NEWLINE <acceptor>-   amount ::=“Pay” NEWLINE <currency> SPACE <value>-   currency ::=[AAA-ZZZ]-   value ::=[0.00-99999999.99]-   acceptor ::=“to:”<name> NEWLINE <street> NEWLINE <city>-   name ::=[A-Za-z0-9] [A-Za-z0-9]*-   street ::=[A-Za-z0-9] [A-Za-z0-9]*-   city :: =[A-Z][A-Za-z0-9]*.

An example contract following the above syntax is

-   “Pay-   USD 20.00-   to: Joe's Grocery Store-   Someroad 20A-   Sometown”

Preferably, the text is adapted to the customer's language and theformat of the currency used by the merchant. Preferably, the text shouldbe sufficiently short to be fully visible in the display of the PTD.When the contract is signed, the PTD may automatically include a UTCtimestamp in the signature returned to the merchant. This makes thesignature unique, assuming that the customer cannot sign more than onecontract per second. Consequently, the collector can ensure that asigned contract can only be used once for authorisation. In step 721,the contract is displayed to the customer by the PTD, and the customeris requested to electronically sign it, e.g. by pressing a “YES” button.Once the contract is signed, the corresponding digital signature isreturned to the PTD servlet Sv1 via a payment request 722. For example,the payment request 722 comprises a WSP GET request including thetransaction ID and the customer's digital signature in the query part ofthe URL. The signature may further comprise an URL to the customer'scertificate, e.g. in the format specified in WAP 1.2 signText( )description including base64 encoded binary data using escape sequencesfor characters otherwise not allowed in an URL. Preferably, the customercertificate comprises the following fields:

-   Serial number: The serial number of the certificate assigned by the    certification authority (CA).-   Signature algorithm: Preferably a secure hash algorithm (SHA-1) with    RSA encryption.-   Issuer: Distinguished name of the CA as specified by the standard    RFC2459 (X.509 certificate profile).-   Subject: Distinguished name of the customer as specified by RFC2459    (X.509 certificate profile).-   Subject Public Key Info: The customer's public RSA key.-   Validity: Validity period of customer's certificate. Represented    using UTC time.-   Extensions: SubjectAltName: encrypted track 2 information, i.e. card    number and expire date. KeyUsage: digitalSignature and    nonRepudiation)

Preferably, the track 2 information is encrypted using the collector'spublic RSA key, ensuring that it can only be decrypted by the collector.Preferably, only the encrypted bytes are used, i.e. no encapsulationaccording to the cryptographic message syntax standard PKCS#7. Hence, anexample of the payment request 722 may be“http://someserver/servlets/PTDServlet?id=20001012123456&signature=kFr4G78i45e46h8g5+4HFi4Ut78H5DDhGKj7bi66nswe.” In step 723,the PTD servlet Sv1 stores the signature in the database 704, updatesthe state of the transaction to “signed”, and forwards the transactioninformation to the collector Col as an authorisation request 724. Forexample, the authorisation request may be implemented using a secure(SSL v.3) HTTPS POST request. The request parameters are passed to thecollector as a signed XML document in the request body. The signeddocument and the merchant's certificate are encoded according to PKCS#7.The document may comprise the following elements:

-   ID: The transaction's ID (equal to the ID in the signed contract),    e.g. a 14 digit integer. The ID is made up of a 4-digit year, a    2-digit month, a 2-digit date, and a 6-digit serial number.-   ACCEPTOR: Identification of the merchant extracted from merchant    certificate, e.g. a 20-digit number constructed by concatenating the    organisation and card acceptor id numbers.-   VAT: The amount of VAT paid by the customer. The currency is the    same as expressed in the contract, e.g. an integer expressing the    amount in the smallest unit of the currency. LOCALE: Indicates the    locale of the contract, i.e. the language and number representation    used to format the contract, e.g. “en-US” for English language and    US as country.-   CONTRACT: The contract signed by the customer, e.g. Base64-encoded    data.

The “CONTRACT” element is constructed by the payment application, e.g.by the following steps:

-   -   The signed contents received from the PTD is decoded (e.g.        base64 and ASN-1/DER) into a data structure as specified in the        WAP 1.2 WML script cryptography library specification.    -   The contract text is inserted into the data structure.    -   The data structure is transformed from WAP standard to PKCS#7        layout and encoded according to PKCS#7.    -   The resulting binary data is base64 encoded.

In the above example, it is assumed that the merchant can be uniquelyidentified from the “ACCEPTOR” element and, combined with thetransaction ID, the request can be uniquely identified. The collectorcompares the “ACCEPTOR” element with the contents of the correspondingcertificate and verifies the identity of the merchant. The locale of thecontract is used when parsing the contract text to extract the totalamount and merchant identity. This allows the collector to handlecontracts in multiple languages and with multiple number formats, e.g.comma instead of dot as decimal separator. An example of anauthorisation request comprising the above fields is

“<!xml version=1.0/> <MeTAuthorisationRequest> <ID>20001012123456</ID><ACCEPTOR>74967396749673967385</ACCEPTOR> <VAT>500</VAT><LOCALE>en-US</LOCALE> <CONTRACT>kFr4G78i45e46h8g5+4HFi4Ut78H5DDhGKj7bi66nswe</CONTRACT></MeTAuthorisationRequest>.”

In step 725, the collector system Col processes the authorisationrequest and returns an authorisation response 726, e.g. as a signed XMLdocument. For example, the document may be signed and encoded togetherwith the collector's certificate in PKCS#7 format, and it may containthe following fields:

-   ID: Transaction ID-   ACCEPTOR: Identification of merchant extracted from merchant    certificate.-   STATUS: Indicates whether authorisation was granted. Status values    may comprise “authorised”, “unknown merchant”, “duplicate    transaction”, “merchant certificate invalid”, “merchant certificate    expired”, “merchant certificate revoked”, “customer certificate    invalid”, “customer certificate expired”, “customer certificate    revoked”, “bad merchant signature”, “bad customer signature”,    “invalid contract”, “invalid date”, “invalid amount”, “system    error”.-   CURRENCY: The currency of total and VAT.-   TOTAL: The total amount authorised.-   VAT: VAT of authorised amount.

Preferably, the authorisation response contains sufficient informationto prove that a particular amount of money has been reserved for aparticular acceptor. Even though the total amount and VAT amount may beinferred from the preceding communication, it is advantageous to have asingle signed document containing all information. An example of such adocument is

“<!xml version=1.0/> <MeTAuthorisationResponse> <ID>20001012123456</ID><ACCEPTOR>74967396749673967385</ACCEPTOR> <STATUS>0</STATUS><CURRENCY>USD</CURRENCY> <TOTAL>2000</TOTAL> <VAT>500</VAT>”</MeTAuthorisationResponse>.”

Preferably, the merchant certificate and the collector certificatecomprise fields corresponding to the fields described above inconnection with the customer's certificate.

In response to the authorisation response 726, the PTD servlet Sv1updates the state of the transaction to “authorised” and returns apayment response 727 to the PTD, causing the PTD to display acorresponding message to the customer. The payment response indicateswhether authorisation was granted, and it may, for example, follow thefollowing syntax:

-   response :=<authorised> | <failed>-   authorised ::=“AUTH” SPACE <currency> SPACE <value>-   currency ::=[AAA-ZZZ]-   value ::=[0,00-99999999,99]-   failed ::=“FAIL” SPACE <reason>-   reason ::=“COMFAILURE” | “INVALIDMERC” “INVALIDCARD” | “EXPIREDCARD”    | “REVOKEDCARD.”

If the payment was authorised, the response includes the authorisedamount. The amount is displayed as part of the confirmation to thecustomer on the PTD. In addition to this electronic confirmation, thecustomer receives a paper receipt from the POS system. If theauthorisation fails, the response includes the reason for the failure.Examples of reasons include:

-   COMFAILURE: The merchant system failed to communicate with the    collector. Either the connection could not be established or there    was an error in the format of the messages.-   INVALIDMERC: The merchant system was not recognised by the    collector. The merchant may not be registered or have an invalid,    expired or revoked certificate.-   INVALIDCARD: The customer's certificate was not recognised by the    collector.-   EXPIREDCARD: The customer's certificate has expired.-   REVOKEDCARD: The customer's certificate has been revoked.

The reasons are used by the PTD to select an appropriate error messageto display to the customer. On the next poll of the polling loop 717 ofthe POS system, the POS servlet Sv2 discovers that the state of thetransaction has been changed to “authorised”, and it reports this to thePOS system as a confirmation response 730. The confirmation responsecomprises the result of the transaction, e.g.

“<!xml version=1.0/> < MeTConfirmationResponse > <RESULT>OK</RESULT> </MeTConfirmationResponse >.”

The POS system may now print a paper receipt and send a receiptnotification request 731 to the POS servlet Sv2, e.g.

“http://someserver/servlets/CashRegisterServlet/receipt?cardno=20001023123456.” In response to the receipt notification request731, the POS servlet Sv2 updates the state of the transaction to“completed” (step 732) and returns a receipt notification response 733to the POS system, e.g.

“<!xml version=1.0/> < MeTReceiptNotificationResponse ><RESULT>OK</RESULT> </ MeTReceiptNotification Response >.”

FIGS. 7 b-c illustrate examples of the message flow in cases where thetransaction is aborted. In the example of FIG. 7 b, the customer cancelsthe transaction before it reaches the “signed” state. When the customerdecides to cancel an ongoing transaction, the PTD sends a cancel request734 to payment application, causing it to inform the POS system that thetransaction has been terminated before it was completed. Morespecifically, when the PTD sends the cancel request 734 to the PTDservlet Sv1, the servlet Sv1 updates the database 704 accordingly andsends a response 736 to the PTD. For example, the cancel request 734 maybe a WSP GET request comprising the transaction ID and the reason forthe cancel request in the query part of the URL, e.g.“http://someserver/servlets/PTDServlet?id=20001012123456&abort=userCancel.” The cancel response may just be an empty message. ThePTD servlet may also return an empty message in response to aninitialisation, contract, or payment request to indicate that thetransaction has been terminated before it was completed. On the nextpoll of the polling loop 717 of the POS system, the POS servlet Sv2discovers that the transaction has been cancelled, and it informs thePOS system about the cancellation via a cancel response 740.

In the example of FIG. 7 c, the cashier cancels the transaction beforeit reaches the “signed” state. When the cashier decides to cancel anongoing transaction, the POS system sends a cancel request 743 to thePOS servlet Sv2 of the payment application, including the ID of thetransaction that is requested to be cancelled, e.g.“http://someserver/servlets/CashRegisterServlet/abort?id=20001023123456.”The POS servlet Sv2 updates the database 704 accordingly (step 744),causing the PTD servlet Sv1 to inform the PTD via a Cancel response 720about the result of the abort, i.e. that the transaction has beenterminated before it was completed, e.g.

“<!xml version=1.0/> <MeTCancelResponse> <RESULT>OK</RESULT> </MeTCancelResponse >.”

Other failure and/or cancel scenarios include the following examples:

-   -   The payment application cancels the transaction before it        forwards the contract to the collector. For example, the        cancellation may be caused by an invalid contract or invalid        customer certificates. When the application cancels the ongoing        transaction, it sends cancel responses to the PTD and POS        system, respectively. The cancel responses may be given in        response to any PTD or POS request.    -   The collector may decline authorisation. In this case, a        negative payment response is sent to the PTD, and a negative        confirmation response is sent to the POS.    -   A communication failure may have occurred, e.g. due to a failure        to connect to a remote system or due to garbled, incomplete, or        invalid contents of a message. Preferably, it is the        responsibility of the PTD and POS system to respond gracefully        to the first category of failures. When this happens, the        payment application should ensure that the ongoing transaction        is marked as failed after a given amount of time. Garbled,        incomplete, or invalid request and response messages should be        handled gracefully by the PTD, POS, collector, and application.        Preferably, this includes reporting the fault to the customer        and/or cashier and to respond with cancel response to a request.    -   A time-out may occur. In order to guard against system lock-up        caused by communication failures or human error, the payment        application may impose a time limit on a transaction, i.e. a        maximum time between the transaction is created and until it has        been cancelled or completed. If a transaction times out, the        application should respond with cancel messages to the PTD and        POS.    -   If the PTD crashes in the middle of a transaction, the        connection to the merchant system will be lost. When/if the        connection is re-established, the PTD will start a new session        with the merchant system.

Consequently, the interrupted transaction will time out if it has notreached the “signed” state. If the contract has been signed, and thecollector grants authorisation, the customer will receive a receipt fromthe POS system as notification that the transaction was completed. Thecustomer will not be issued a new contract in this case.

-   -   If the payment application crashes in the middle of a        transaction, it will treat all transactions, which have not        reached “completed” state, as aborted. Once the application        restarts, the interrupted transactions will be closed and cancel        messages will be sent to the POS and PTD (if they have not        discovered the crash). This ensures that capture is not        performed against incomplete transactions, i.e. If the customer        has not received a receipt from the POS system, capture will not        be performed.    -   If the POS system crashes in the middle of a transaction, the        transaction will time out, causing cancel messages to be sent to        the PTD. Because the transaction did not reach “completed”        state, capture will not be performed for it.    -   If the collector crashes before an authorisation request has        been fully processed, the application does not receive an        authorisation response. This will cause the transaction to time        out and consequently cancel messages will be sent to the PTD and        POS system.

In the above scenarios, if the customer has signed an electroniccontract before the transaction aborts, the POS system should print anegative paper receipt to be used by the customer as proof that thesignature is not going to be used. In the scenario where the paymentapplication crashes, this may require that the POS system is adapted totime out after a predetermined time while waiting for the paymentapplication. In the scenario where the POS crashes, a receipt may beissued by other means, e.g. manually.

FIG. 7 d illustrates an example of a message flow in connection with thecapture of a payment. The messages are exchanged between the merchantsystem Sv and the collector system Col. Preferably, the merchantinitiates capture of transactions, typically at the end of a businessday. This causes the collector to create a batch job containingauthorised transactions for the merchant, and to submit this batch jobto the acquirer system. In the example of FIG. 7 d, when the merchantsystem Sv initiates capture, it uses a secure (SSL v.3) HTTPS POSTrequest 748 to transmit the capture parameters to the collector as asigned XML document in the request body. Preferably, the documentcontains sufficient information to prove that capture has been requestedfor a particular set of transactions, while the exact nature of thetransactions may be verified from preceding authorisation requests. Forexample, the capture request 748 may comprise a list of thetransactions, which the merchant wishes to include in the capture, i.etransactions having reached the “completed” state. The signed documentand the merchant's certificate are encoded according to PKCS#7. Thedocument may comprise the following elements:

-   ACCEPTOR: Identification of the merchant extracted from the merchant    certificate.-   TRANSACTION: ID of transactions to be included in the capture.

An example of a capture request comprising the above fields is:

“<!xml version=1.0/> <MeTCaptureRequest><ACCEPTOR>74967396749673967385</ACCEPTOR><TRANSACTION>20001107034512</TRANSACTION><TRANSACTION>20001107034513</TRANSACTION><TRANSACTION>20001107034514</TRANSACTION> </MeTCaptureRequest>.”

Again, in the above example, it is assumed that the merchant can beuniquely identified from the ACCEPTOR element. The collector shouldcompare the ACCEPTOR element with the contents of the certificate andverify the identity of the merchant.

The collector system Col processes the request (step 749) and replies bysending a capture response 750 to the merchant system Sv, comprising adocument which contains sufficient information to prove, that capturehas been initiated for a particular set of transactions. For example,the document may be an XML document signed and encoded together with thecollector's certificate in PKCS#7 format. The XML document may comprisethe following elements:

-   ID: Capture ID, e.g. a 14 digit integer, e.g. made up of a 4-digit    year, a 2-digit month, a 2-digit day, and a 6-digit serial number.-   ACCEPTOR: Identification of the merchant extracted from the merchant    certificate.-   STATUS: Indicates whether capture was accepted. Examples of status    values include “Capture in progress”, “unknown merchant”, “merchant    certificate invalid”, “merchant certificate expired”, “merchant    certificate revoked”, “bad merchant signature”, “system error”.-   TRANSACTION: ID of transactions included in the capture.

An example of a capture response comprising the above fields is:

“<!xml version=1.0/> <MeTCaptureResponse> <ID>20000912000010</ID><ACCEPTOR>74967396749673967385</ACCEPTOR> <STATUS>0<STATUS><TRANSACTION>20001107034512</TRANSACTION><TRANSACTION>20001107034513</TRANSACTION><TRANSACTION>20001107034514</TRANSACTION> </MeTCaptureResponse>.”

The response 750 tells the merchant system whether the capture requestwas accepted, thereby indicating whether a subsequent capture report canbe obtained from the collector system. The capture report tells themerchant that money has been transferred to the account of the businessor, in case of failures, what has gone wrong. It is advantageous toprovide both a capture response and a capture report, because theacquirer system may need a significant amount of time to process thebatch job, i.e. the capture request would time out before the acquirersystem could respond to the collector. For example, the merchant systemmay use a HTTPS POST request 751 to request a capture report comprisingthe capture ID and an “ACCEPTOR” field as described above, e.g.

“<!xml version=1.0/> <MeTReportRequest> <ID>20000912000010</ID><ACCEPTOR>74967396749673967385</ACCEPTOR> </MeTReportRequest> .”

The corresponding report is returned in a response 753 which maycomprise a signed XML document, encoded together with the collector'scertificate in PKCS#7 format and comprising the following fields

-   ID: Capture ID.-   ACCEPTOR: Identification of the merchant extracted from the merchant    certificate.-   STATUS: Indicates whether the capture succeeded.-   INFO: Additional information if the capture was rejected, e.g. a    text string.-   CURRENCY: The currency of credit and debit.-   CREDIT: Total amount transferred to the merchant's account.-   DEBIT: Total amount deducted from the merchant's account.

An example of a report response comprising the above fields is:

“<!xml version=1.0/> <MeTReportResponse> <ID>20000912000010</ID><ACCEPTOR>74967396749673967385</ACCEPTOR> <STATUS>0<7STATUS><CURRENCY>USD</CURRENCY> <CREDIT>120000</CREDIT> <DEBIT>0</DEBIT></MeTReportResponse>.”

Should the application crash before a capture response has been receivedfrom the collector, the capture request may be retransmitted. Thecollector may respond with a capture response message containing thetransactions of the original capture request, even though newtransactions have been added to the new request. This ensures that analready submitted batch job can be processed. The merchant applicationshould detect the difference between the request and the response andgenerate a new capture request containing the transactions not includedin the first batch job. Should the application crash before a capturereport has been received from the collector, the report request may beretransmitted. The merchant application may request a report for a givenbatch job as many times as it wants. If the collector crashes in themiddle of a capture request, the merchant system will not receive acapture response. Consequently, the request will time out, and a newrequest can be made, as described above.

In the above examples, the interactions between the PTD and the merchantsystem are based on WAP connections. The connection may use transportlayer security (WTLS) class 2 or class 3. Class 2 allows the PTD toauthenticate the server's identity, whereas class 3 allows the server toauthenticate the customer's identity. The latter may not be necessary asthe signature on the contract serves as identification of the customer.To ensure sufficient encryption strength, the cipher key size should,preferably, be 128 bit and the public RSA key size 1024 bit. CA publicRSA keys are preferred to be 2048 bits long. The MIME type of allresponses is “text/plain”. Furthermore, in the above examples, theinteractions between the application and the POS system is based on HTTPconnections. It is assumed that the LAN provides sufficient protectionof the connections, i.e. encryption is not necessary. The interactionsbetween the merchant system and the collector are based on HTTPSconnections. Security is provided using SSL v.3 to provide privacy andintegrity through encryption. To ensure sufficient encryption strength,the cipher key size should be 128 bit and the public RSA key size 1024bit. CA public RSA keys are to be 2048 bits long. Alternatively oradditionally, other protocols and security standards may be used withinthe scope of the invention.

It should be noted, that the flow described in connection with theexamples of FIGS. 7 a-d is based on polling. The use of polling solvesthe problem that WSP and HTTP GET requests may time out. Consequently, aresponse to a GET request may not be arbitrarily delayed, therebylimiting the maximum waiting time which may be implemented. Inparticular, this is a disadvantage in cases where the execution of theflow requires human interaction, i.e. where fixed response times cannotbe guaranteed. The use of polling solves this problem, as the waiting isimplemented in the requesting device, allowing the application torespond immediately to a GET request. Alternatively, the timeout problemwith WSP requests can be avoided using WAP push technology by pushing anURL to the PTD. This has the further advantage that it avoidsunnecessary delays of the polling technique. Using polling, in a worstcase scenario, the maximum sleep intervals of all polling loop should beadded to the time it takes to complete a transaction.

The above example embodiments have primarily been described inconnection with examples employing the technologies Bluetooth, WAP, andHTTP. However, other technologies as well as other ways of providingsecurity and performing the transaction are understood to be within thescope of the described technology.

1. A method of processing a transaction request by a first customermobile terminal at a transaction system, the method comprising:establishing via at least one wireless access point respective wirelesscommunications links between the transaction system and a number ofcustomer mobile terminals corresponding to respective customers, thetransaction system including a point of sale system and a serverconnected to the point of sale system and to the at least one wirelessaccess point; wirelessly transmitting a transaction request from thefirst customer mobile terminal to the server via said at least onewireless access point; in response to the transaction request,generating by the server an identifier identifying the first customermobile terminal; transmitting the identifier from the server to thefirst customer mobile terminal via said at least one wireless accesspoint; and identifying at the point of sale system the first customermobile terminal among the number of customer mobile terminals havingestablished a respective wireless communications link as being acustomer mobile terminal carried by a selected customer by communicatingthe identifier to the point of sale system, wherein identifying thefirst customer device includes: assigning respective identifiers to eachof the number of customer mobile terminals by the transaction system, afirst identifier being assigned to the first customer mobile terminal;transmitting the respective identifiers from the transaction system tothe corresponding customer mobile terminals via the correspondingwireless communications links; and using the first identifier toidentify the first customer mobile terminal carried by the selectedcustomer, wherein the first identifier has a length determined by thetransaction system based on the number of customer mobile terminalshaving established a wireless communications link with the transactionsystem.
 2. A method according to claim 1, wherein the first identifieris a sequence of alphanumeric characters.
 3. A method according to claim2, wherein the first identifier comprises less than five characters. 4.A method according to claim 1, wherein using the first identifier toidentify the first customer device comprises: presenting the firstidentifier to the selected customer by the first customer device; andreceiving a first input by the transaction system from a user of thetransaction system, the first input being indicative of the firstidentifier.
 5. A method according to claim 1, further comprising:storing in a storage medium a set of customer data items in relation toa set of device data items, the set of customer data items beingindicative of a set of registered customers and the set of device dataitems being indicative of a corresponding set of customer devices;presenting to a user of the transaction system selected ones of the setof customer data items related to the customer devices havingestablished respective wireless communications links; and receiving asecond input by the transaction system from the user of the transactionsystem, the second input being indicative of a selected one of thepresented customer data items.
 6. A method according to claim 5, whereinpresenting selected ones of the set of customer data items furthercomprises selecting a subset of the number of customer devices based onadditional information about the customer devices.
 7. A method accordingto claim 6, wherein the additional information comprises receptioncharacteristics of at least the established wireless. communicationslinks.
 8. A method according to claim 5, wherein presenting selectedones of the set of customer data items further comprises presenting theselected customer data items in a predetermined order based onadditional information about at least one of the customer data and thecustomer devices.
 9. A method according to claim 1, wherein thetransaction includes a transfer of a predetermined amount from acustomer account to a recipient account, and the method furthercomprises: transmitting a second data signal indicative of thepredetermined amount from the transaction system to the first customerdevice via the corresponding wireless communications link; receiving athird input from the selected customer to the wireless customer device,the third input being indicative of an authorization to transfer thepredetermined amount from the customer account to the recipient account;transmitting the first data signal in response to the third input;initiating transfer of the predetermined amount by the transaction; andsystem in response to the received first data signal.
 10. A methodaccording to claim 1, wherein at least a first one of the respectivewireless communications links is a Bluetooth link.
 11. A computerprogram embodied in a computer-readable medium comprising program codefor performing the steps of claim 1 when said computer program is run ona computer.
 12. A method according to claim 1, wherein furthercomprising: transmitting the identifier from the point of sale system tothe server; based on the received identifier, creating a contract by theserver; and transmitting the contract to the first customer device inorder for the customer of the first customer mobile terminal to approvethe transaction request.
 13. A transaction system for processing atransaction request to be approved by a first customer mobile terminal,the transaction system comprising: a transceiver included at a wirelessaccess point for establishing respective. wireless communications linksbetween the transaction system and a number of customer mobileterminals; wherein the transaction system includes a point of salesystem; a server, connected to the point of sale system and to thewireless access point; and arranged to receive a transaction requestwirelessly transmitted from a first customer mobile terminal via thewireless access point, wherein the server is arranged to generate afirst identifier identifying the first customer mobile terminal inresponse to the transaction request and to transmit the identifier tothe first customer mobile terminal via the wireless access point;wherein the point of sale system is arranged receive the firstidentifier output by the first customer mobile terminal and to identifythe first customer mobile terminal among the number of customer mobileterminals having established a respective wireless communications linkas being a customer mobile terminal carried by a selected customer basedon the first identifier having been output by the first customer mobileterminal, wherein: the server is arranged to assign a respectiveidentifier to each of the number of customer mobile terminals; thetransceiver is arranged to transmit the respective identifiers from thetransaction system to corresponding customer mobile terminals via thecorresponding wireless communications links; and the first identifierhas a length determined by the transaction system based on the number ofcustomer mobile terminals having established a wireless communicationslink with the transaction system.
 14. A transaction system according toclaim 13, wherein the server comprises: a first output for presentingthe first identifier to the selected customer; and a first input forreceiving a first input from a user of the transaction server, the firstinput being indicative of the first identifier.
 15. A transaction systemaccording to claim 13, further comprising: a storage medium arranged tostore a set of customer data items in relation to a set of device dataitems, the set of customer data items being indicative of a set ofregistered customers and the set of device data items being indicativeof a corresponding set of customer mobile terminals; a second output forpresenting selected ones of the set of customer data items to a user ofthe transaction system; and a second input for receiving a second inputfrom the user, the second input being indicative of a selected one ofthe presented customer data items.
 16. A transaction system according toclaim 13, wherein the transaction request includes a request to transfera predetermined amount from a customer account to a recipient account;the transceiver is adapted to transmit a second data signal indicativeof the predetermined amount from the transaction system to the firstcustomer mobile terminal via the corresponding wireless communicationslink; the first customer device comprises a third input for receiving athird input from the selected customer, the third input being indicativeof an authorization to transfer the predetermined amount from thecustomer account to the recipient account; the transceiver is furtheradapted to transmit the first data signal in response to the thirdinput; and the transaction system further comprises a second server forinitiating the transfer of the predetermined amount by the transactioncomponent in response to the received first data signal.
 17. A customermobile terminal for processing a transaction request from a point ofsale (POS) transaction system, the customer mobile terminal comprising:a transceiver for establishing a short-range wireless communicationslink between the customer mobile terminal and the transaction system viaat least one wireless access point, the transaction system including apoint of sale system and a server connected to the point of sale systemand to the at least one wireless access point; and a processor forassisting the transaction system in identifying the customer mobileterminal among a number of customer mobile terminals having establishedrespective short-range wireless communications links as being a customermobile terminal carried by a selected customer, wherein the processor isarranged to: wirelessly transmit a transaction request via the wirelessaccess point to the server; receive an identifier identifying thecustomer mobile terminal from the server via the wireless access point;and output the received identifier so as to allow the point of salessystem to identify the customer mobile terminal among the number ofcustomer mobile terminals having established a respective wirelesscommunications link as being a customer mobile terminal carried by aselected customer based on the identifier having been output by thefirst customer mobile terminal, wherein a length of the identifieridentifying the customer mobile terminal is based on the number ofcustomer mobile terminals having established a wireless communicationslink with the transaction system.
 18. A transaction system forprocessing a transaction request to be approved by a first customermobile terminal, the transaction system comprising; a transceiver at awireless access point for establishing respective wirelesscommunications links between the transaction system and a number ofcustomer mobile terminals; a point of sale system; and a server,connected to the point of sale system and to the wireless access point,arranged to receive a first transaction request wirelessly transmittedfrom the first customer mobile terminal via the wireless access point,and in response to the first transaction request, to generate atransaction record comprising first identifier and store the transactionrecord in a database, the database storing a number of transactionrecords indicative of respective customer mobile terminals havingtransmitted a transaction request, wherein the server is furtherarranged to, in response to a second transaction request from the pointof sale system, present the number of transaction records and associatedcustomer information on the point of sale system; wherein the point ofsale system is arranged to identify the first customer mobile terminalamong the number of customer mobile terminals having establishedrespective wireless communications links as being a customer devicecarried by a selected customer based on the associated customerinformation presented on the point of sale system including the firstidentifier; and wherein a length of the first identifier is based on thenumber of customer mobile terminals having established a wirelesscommunications link with the transaction system.
 19. A method ofprocessing a transaction request by a first customer mobile terminal ata transaction system; the method comprising: establishing respectivewireless communications links between the transaction system and anumber of customer mobile terminals corresponding to respectivecustomers via at least one wireless access point, the transaction systemincluding a point of sale system and a server connected to the point ofsale system and to the at least one wireless access point; wirelesslytransmitting a first transaction request from the first customer mobileterminal to the server via said at least one wireless access point; inresponse to the first transaction request, generating by the server atransaction record comprising an identifier and storing the transactionrecord in a database, the database storing a number of transactionrecords indicative of respective customer mobile terminals havingtransmitted a transaction request; communicating a second transactionrequest from the point of sale system to the server; in response to thesecond transaction request, presenting the number of transaction recordsand associated customer information on the point of sale system;identifying at the point of sale system the first customer mobileterminal among the number of customer mobile terminals based on theassociated customer information presented on the point of sale system.20. A method according to claim 19, further comprising: transmitting theidentifier from the point of sale system to the server; based on thereceived identifier, creating a contract by the server; and transmittingthe contract to the first customer mobile terminal in order for thecustomer of the first customer mobile terminal to approve thetransaction request.
 21. A method according to claim 19, wherein theassociated customer information presented on the point of sale systemincludes an identifier associated with the first customer mobileterminal and a length of the identifier is based on the number ofcustomer mobile terminals having established a wireless communicationslink with the transaction system.